Windows Search Totally Explained

Everything about Windows Search totally explained

Windows Search (known as Windows Desktop Search or WDS on Windows XP and Windows Server 2003) is an indexed desktop search platform released by Microsoft for the Windows operating system. Windows Search for Windows Vista and Windows Server 2008 (also referred as Instant Search) is a successor of the Windows Indexing Service, a remnant of the Object File System feature of the Cairo project which never materialized. Windows Search uses a different architecture and a new indexer compared to Indexing Service. For Windows XP, Windows Desktop Search is available as an add-on application. Windows Search collectively refers to both Indexed Search on Windows Vista and WDS on Windows XP. They not only share a common architecture and indexing technology, Windows Search by default includes handlers for common filetypes, including Word documents, Excel spreadsheets, PowerPoint presentations, HTML documents, text files, MP3 and WMA music files, WMV, ASF and AVI videos, JPEG, BMP and PNG images, among others. It uses property handlers to handle metadata from file formats. A property handler needs a property description and a schema for the property for WDS to index the metadata. Protocol handlers are used for indexing specific data stores. For example, files are accessed using File System Protocol Handler, Outlook datastores using the Outlook Protocol Handler and IE cache using the IE History/Cache Protocol Handler. Network shares can be added to the index by installing proper property-handlers.

Architecture

Windows Search is implemented as a Windows Service which implements the Windows Search runtime and APIs, as well as acting as host for the index stores and controlling the components. The most important component of Windows Search is the Indexer, which crawls the file system periodically and creates and maintains the index of the data. It achieves this using three processes:

SearchIndexer.exe, which hosts the indexes and the list of URIs that require indexing, as well as exposes the external APIs that other applications use to leverage the Windows Search features.
SearchProtocolHost.exe, which hosts the protocol handler. It runs with the least permission required for the protocol handler. For example, when accessing filesystem, it runs with the credentials of the system account, but on accessing network shares, it runs with the credentials of the user.
SearchFilterHost.exe, which hosts the IFilter and property handlers to extract metadata and textual content. It is a low integrity process, which means that it doesn't have any permission to change the system settings. So, even if it encounters files with malicious content, and by any chance if they manage to take over the process, they won't be able to change any system settings.

The Indexer consists of two components, the Gatherer and the Merger, the Gatherer retrieves the list of URIs that need to be crawled and invokes proper protocol handler to access the store that hosts the URI, and then the proper Property-handler (to extract metadata) and IFilter to extract the document text. Different indices are created during different runs; it's the job of the Merger to periodically merge the indices. AQS defines certain keywords which can be used to refine the search query, such as specifying boolean operations on searched terms (AND, OR, NOT) as well as to specify further filters based on file metadata or file type. It can also be used to limit results from specific information stores like regular files, offline files cache, or email stores. File type specific operators are available as well. WDS also supports wildcard searches. It also includes several SQL-like operators like GROUP BY.

Programmability

The Windows Search index can be accessed programmatically using both managed as well as native code. Native code connects to the index catalog by using a Data Source Object retrieved from the shell's Indexing Service OLE DB provider. Managed code use the MSIDXS ADO.NET provider with the index catalog name. A catalog on a remote machine can also be specified using a UNC path. The criteria for the search is specified using SQL, though some operators are restricted. The SQL query can either be created by hand, or by using an implementation of the ISearchQueryHelper interface. Windows Search provides implementations of the interface to convert an AQS or NQS queries to their SQL counterpart.
   The OLE DB/SQL API implements the functionality for searching and querying across the indices and property stores. It uses a variant of SQL to represent the query in (regular SQL with certain restrictions). Results are returned as OLE DB Rowsets. An SQL query can directly refer these tables and index catalogues and use the MSIDXS provider to run queries against them. The search index can also be used via OLE DB, using the CollatorDSO provider. However, the OLE DB provider is read-only, supporting only SELECT and GROUP ON SQL statements.
   Windows Search also registers a search-ms application protocol, which can be used to represent searches as URIs. The search parameters and filters are encoded in the URI using AQS, or its natural language counterpart, NQS. When the URI is invoked, Windows Search (which is registered as handler for the protocol) launches the Search Explorer with the results of the search. Windows Search is currently the default handler for the protocol, but with Windows Vista SP1, third party handlers will be able to register themselves as the protocol handler, so that searches can be performed using any search engine which the user has set as default, and not just Windows Vista.
   The Windows Search service provides the Notifications API component to allow applications to "push" items that need indexing to the Windows Search indexer. If the file is in a location indexed by Windows Search and doesn't have the FANCI (File Attribute Not Content Indexed) attribute set, It also exposes APIs to register protocol handlers (via the ISearchProtocol interface, property handlers (via the IPropertyStore interface) or IFilter implementations (via the IFilter interface). IFilter implementations allow only extraction of text, whereas IPropertyStore allows reading as well as modifying properties, both to the file and the property store database. version 3.0 of Windows Desktop Search was provided as a standalone release - separate from Windows Live Toolbar. WDS 3.01 is geared for pre-Windows Vista users, hence the indexer was implemented as a Windows Service, rather than as a per-user application, so that the same index as well as a single instance of the service can be shared across all users - thereby improving performance. WDS found itself in the midst of a controversy on October 25, 2007 when WDS 3.01 was automatically pushed out and installed to Windows systems when they updated themselves via WSUS. Microsoft hasn't yet responded on the situation.

Windows Search

Windows Search is the indexed search platform in Windows Vista and Windows Server 2008, and offers a superset of the features provided by Windows Desktop Search, while being API compatible with it. Unlike WDS, it can seamlessly search indexed as well as non-indexed locations - for indexed locations the index is used and for non-indexed locations, the property handlers and IFilters are invoked on the fly as the search is being performed. This allows for more consistent results, though, at the cost of searching speed. Windows Search uses Group Policy for centralized management.
Windows Search indexes offline caches of network shares, in addition to the file systems, Microsoft Outlook e-mail stores and Microsoft OneNote stores indexed by WDS. Natural language search expresses the queries in Natural Query Syntax (NQS), which is the natural language equivalent of AQS.

User interface

The search functionality is exposed using the search bars in the Start menu and the upper right hand corner of Windows Explorer windows, as well as Open/Save dialog boxes. When searching from the Start menu, the results are shown in the Start menu itself, overlapping the recently used programs. From the Start menu, it's also possible to launch an application by searching for its executable image name or display name. Searching from the search bars in Explorer windows replaces the content of the current folder with the search results. The Explorer windows can also render thumbnails in the search results if a Thumbnail Handler is registered for a particular file type. It can also render enhanced previews of items in a Preview Pane without launching the default application, if the application has registered a Preview Handler. This can provide functionality such as file type-specific navigation (such a browsing a presentation using next/previous controls, or seeking inside a media file). Preview handlers can also allow certain kind of edits (such as highlighting a text snippet) to be performed from the preview pane itself. In the Control Panel, the search bar in the window can also search for Control Panel options. However, unlike WDS, Windows Search doesn't support creating aliases. There is also a Search Explorer, which is an integrated Windows Explorer window that's used for searches. It presents the user interface to specify the search parameters, including locations and file types that should be searched, and certain operators, without crafting the AQS queries by hand. With Windows Vista SP1, third party applications will be able to override the Search Explorer as the default search interface so that the registered third party application will be launched, instead of bringing up the Search Explorer, when invoked by any means. However, the Windows Search indexer won't be disabled after doing this, and the search bars will still continue to use the Windows Search index.
In Windows Search, which is part of Windows Vista, it's also possible to save a search query as a Virtual Folder, called a Saved Search or Search Folder, Search Folders are also distributable via RSS. They can also be shared as a SearchMelt, which is accessible over a network. Accessing a SearchMelt over the network, like a regular Search Folder, makes the results of the search available as a virtual shared folder. The search will be performed on the machine which shares the SearchMelt, and will return only the results accessible from the network. However, by default, search folders are scoped for local use only; before sharing, they must be configured for remote access. Microsoft makes a SearchMelt Creator tool available for this as well.

Windows Search 4.0

Windows Search 4.0 is the successor to the Windows Search platform, for both Windows Desktop Search 3.0 on Windows XP as well as Instant Search on Windows Vista. It was initially developed as a research project as Windows Live Search Center, as well as perform searches against web services, which uses OpenSearch specification to make available the search results as a web feed, and present the results in a unified interface.
The first beta of Windows Search 4.0 was released on March 27, 2008. It includes numerous performance improvements to the indexer as well as brings new features, including previously Windows Vista-exclusive ones to Windows XP - including Group Policy integration, federation of searches to remote indexes, support for EFS-encrypted files and Windows Vista-style preview handlers that allow document-type specific browsing of documents in the preview pane. It doesn't currently include the search federation capabilities of Windows Live Search Center - which allows searches to be delegated to remote web services using OpenSearch specification, like Microsoft Search Server. Windows Search 4.0 is supported on Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008 as well as Windows Home Server.

Further Information

Get more info on 'Windows Search'.

External Link Exchanges

Do you know how hard it is to get a link from a large encyclopaedia? Well we're different and will prove it. To get a link from us just add the following HTML to your site on a relevant page:

<a href="http://windows_search.totallyexplained.com">Windows Search Totally Explained</a>

Then simply click through this link from your web page. Our crawlers will verify your link, extract the title of your web page and instantly add a link back to it. If you like you can remove the words Totally Explained and embed the link in article text.
As long as your link remains in place, we'll keep our link to you right here. Please play fair - our crawlers are watching. Your site must be closely related to this one's topic. Any kind of spamming, dubious practises or removing the link will result in your link from us being dropped and, potentially, your whole site being banned.